Key project drafts by project id so deleting a project clears their state - #365
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #364. Pre-existing bug:
ConversationDestination::ProjectDraftwas built with the draft's session id by the runtime (conversation_destination) and the UI store (destination), while project deletion, the composer and the persisteddraft:<id>preference key all use the project id. Deleting a project therefore never cleared the draft's terminal workspace, terminal preferences orconversation_uientry, and draft terminal preferences were persisted under an unreachable key.Change
sync_active_conversation_uimatches on the committed thread's project instead of comparing ids.IndexSnapshotarm dropsconversation_uientries whose project or session is no longer listed. The runtime never emitsIndexRemoveProject; index replication is snapshot-based, so this is the pathCommand::DeleteProjectactually takes. Archived threads stay listed, so archiving keeps its state.reconcile_destinationtreats a selected draft whose project left the index like a vanished thread and falls back to another project's draft.Tests
deleting_a_project_clears_its_drafts_terminal_state(terminal workspace anddraft:<project>preferences gone afterdelete_project).Command::DeleteProjecton the real host: background draft state cleared without moving the user; viewing the deleted project's draft lands on another project's draft with no stranded state; committing a draft still carries its UI state to the thread.Behaviour note
Two live drafts for one project (only reachable through multiple mux clients at different roots) now share per-project draft terminal preferences and one parked terminal-workspace slot, consistent with the documented "an unsent draft follows its project" keying and the composer's existing behaviour.
Checks
cargo fmt --all --check,cargo clippy --workspace --all-targets --locked -- -D warnings,cargo test --workspace --lockedpass locally on macOS. Mobile/Web andcargo macheteleft to CI.